home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000350_timbl@www3.cern.ch _Thu Nov 19 12:06:46 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA13717; Thu, 19 Nov 92 12:06:46 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA25218; Thu, 19 Nov 92 12:19:16 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA00242; Thu, 19 Nov 92 12:14:52 +0100
  8. Date: Thu, 19 Nov 92 12:14:52 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9211191114.AA00242@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: marca@ncsa.uiuc.edu (Marc Andreessen)
  14. Subject: Re: hangs/multiple servers
  15. Cc: www-talk@nxoc01.cern.ch
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18. > Also, is there any way to specify backup servers?  Does anyone else
  19. > think this would be useful?
  20.  
  21. Yes... it certainly would.
  22.  
  23.  
  24.  First of all, the final solution seems to be to use a globally distributed  
  25. replicated name server for documents or servers. Like x500 which isn't here  
  26. yet. The name service would return multiple pointers. The client could chose
  27.  intelligently which to try first.  But we don't have that infrastructure yet.
  28.  
  29.  
  30. In the mean time, the question is where to put the information.
  31. In teh new HTTP protocol there are a number of objects which can be
  32. returned ateth protocol level (rather than the data level) which include
  33. error objects and forwards. A forward can contain multiple pointers.
  34.  However, it doesn't help reliability much because the server which hold the  
  35. forwarding info will be just as unreliable! 
  36.  
  37.  
  38.  
  39. So one considers putting the multiple URLs (addresses) into the link in the
  40. document.  This smells too, because the positions of servers for different
  41. parts of the abstract document space will be constantly evolving, and so the
  42. links will be soon out of date, and that is grim for documents which may last  
  43. 20 years...
  44.  
  45. The next solution Rik just mentioned:
  46. >  One possible way to implement backups is to have the client do it (makes
  47. >  the client too clever?).  The client could have a list of hosts, and for
  48. >  each one, have a list of backup servers, to try if the main server is
  49. >  down.  The problem with this is that the list is much more difficult
  50. >  to maintain, if everyone needs a copy, and only the clients that have
  51. >  implemented this would benefit.
  52.  
  53. But it is a simple stopgap.  The way I would see doing it
  54. in practice would be to call the name translation rule module (HTRules.c)
  55. from the client as currently from the daemon httpd. The rules would
  56. be extended to include a "try" operator, like "map" but
  57. allowing continues processing of the rule file if the access failed.
  58.  
  59. This would be useful in the server too... for example to pick up date from some
  60. remote mounted disk which is the original, but if that fails to use a cached  
  61. copy updated last night.
  62.  
  63. Tim
  64.